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I. REAL PARTY IN INTEREST 

The real party in interest for this appeal is Samsung Electronics Co., Ltd., the assignee of 

record. 



II. RELATED APPEALS AND INTERFERENCES 

There are no other appeals, interferences, or judicial proceedings which will directly 
affect or be directly affected by or have a bearing on the Board's decision in this appeal. 
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III. STATUS OF CLAIMS 

A. Total Number of Claims in Application 

There are fourteen (14) claims pending in application. The application contains claims 6, 
8-11, 13-15, 20, and 23-27, which were finally rejected. This is an appeal from the final 
rejection of claims 6, 8-11, 13-15, 20, and 23-27. 

B. Current Status of Claims 

1. Claims canceled: 1-5, 7, 12, 16-19, and 21-22. 

2. Claims withdrawn from consideration but not canceled: None. 

3. Claims pending: 6, 8-11, 13-15, 20, and 23-27. 

4. Claims allowed: None. 

5. Claims rejected: 6, 8-11, 13-15, 20, and 23-27. 

C. Claims On Appeal 

The claims on appeal are claims 6, 8-11, 13-15, 20, and 23-27. 

IV. STATUS OF AMENDMENTS 

Claims 6, 8-11, 13-15, 20, and 23-27 have been amended to correct grammatical and 
typographical errors unrelated to any rejection in the April 23, 2010, Final Rejection, and the 
Examiner indicated in the June 28, 2010, Advisory Action that the amendments would be entered 
for the purposes of appeal. A Notice of Appeal was filed on July 16, 2010. 



3 



Application No. 10/782,193 Attorney Docket No. 12000.SMG.0008 

Appeal Brief 

V. SUMMARY OF CLAIMED SUBJECT MATTER 

The invention is directed to "an apparatus and method for transmitting packet data in a 
communication system, and more particularly to an apparatus and method for aggregately 
transmitting packet data in a communication system." Specification, page 1, In. 10-12. 
Accordingly, a concise explanation of the subject matter defined in each of the independent 
claims involved in the appeal are summarized below in accordance with 37 CFR § 41.37(c)(v). 

6. An apparatus [FIG. 9] for generating an aggregation packet [FIG. 4, 332; FIG. 5, 342] 
in a communication system [Page 4, In. 16-17], the apparatus comprising: 

a buffer manager configured to store a plurality of data packets [FIG. 9, 920]; and 

an aggregation module configured to receive the plurality of data packets from the buffer 
manager [FIG. 9, 930] and aggregating at least two data packets comprising a same destination 
address [Page 5, In. 10-11] and identical quality of service information [Page 6, In. 3-4] among 
the plurality of received data packets to form a single aggregated packet, a header of each of 
the at least two data packets comprising length information and a destination address [Page 5, 
In. 8-9], a header of the aggregated packet comprising a destination address which is identical to 
the destination address included in the header of the at least two data packets [Page 5, In. 10-14]. 
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1 1 . A method for generating an aggregation packet in a communication apparatus of a 
wireless communication system [Page 4, In. 16-17], the method comprising: 

receiving a plurality of data packets in a buffer manager of the communications apparatus 
[FIG. 9,920]; 

aggregating, by an aggregation module of the communications apparatus [FIG. 9, 930], at 
least two data packets comprising a same destination address [Page 5, In. 10-11] and identical 
quality of service information [Page 6, In. 3-4] among the plurality of received data packets; and 

generating, by the communications apparatus, a single aggregation packet from the 
aggregated packets by adding a header to the aggregated packets [Page 6, In. 30 - Page 7, In. 1], 
a header of each of the at least two data packets comprising length information and a destination 
address [Page 5, In. 8-9], the header of the aggregation packet comprising a destination address 
which is identical to the destination address included in the header of the at least two data 
packets [Page 5, In. 10-14], 

20. A method of generating an aggregation packet in communication apparatus of a 
wireless communication system [Page 4, In. 16-17], the method comprising: 

receiving, by a buffer manager of the communications apparatus, a plurality of data 
packets and quality of service information associated with the packets, each of the data packets 
comprising a destination address and length information [FIG. 9, 920; Page 5, In. 8-9]; 
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aggregating, by an aggregation module of the communications apparatus [FIG. 9, 930], at 
least two data packets comprising the same destination address [Page 5, In. 10-11] and identical 
quality of service information [Page 6, In. 3-4] among the plurality of received data packets; and 

generating a single aggregation packet from the aggregated packets by adding a header to 
the aggregated data packets [Page 6, In. 30 - Page 7, In. 1], the header comprising the destination 
address of the aggregated data packets [Page 5, In. 10-14]. 

26. An apparatus [FIG. 9] for generating an aggregation packet [FIG. 4, 332; FIG. 5, 
342] in a communication system [Page 4, In. 16-17], the apparatus comprising: 

a buffer manager for storing a plurality of data packets [FIG. 9, 920]; and 

an aggregation module for receiving the plurality of data packets from the buffer manager 
[FIG. 9, 930] and aggregating at least two data packets comprising a same destination address 
[Page 5, In. 10-11] and identical quality of service (QoS) parameters [Page 6, In. 3-4] among the 
plurality of received data packets to form a single aggregated packet, a header of each of the at 
least two data packets comprising length information and a destination address [Page 5, In. 8-9], 
a header of the aggregated packet comprising a destination address which is identical to the 
destination address included in the header of the at least two data packets [Page 5, In. 10-14]. 
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27. A method for generating an aggregation packet in a communication apparatus of a 
wireless communication system [Page 4, In. 16-17], the method comprising the steps of: 

receiving a plurality of data packets in a buffer manager of the communications apparatus 
[FIG. 9,920]; 

aggregating, by an aggregation module of the communications apparatus [FIG. 9, 930], at 
least two data packets comprising a same destination address [Page 5, In. 10-11] and identical 
quality of service (QoS) parameters [Page 6, In. 3-4] among the plurality of received data 
packets; and 

generating, by the communications apparatus, a single aggregation packet from the 
aggregated packets by adding a header to the aggregated packets [Page 6, In. 30 - Page 7, In. 1], 
a header of each of the at least two data packets comprising length information and a destination 
address [Page 5, In. 8-9], the header of the aggregation packet comprising a destination address 
which is identical to the destination address included in the header of the at least two data 
packets [Page 5, In. 10-14]. 

VI. GROUND(S) OF REJECTION TO BE REVIEWED ON APPEAL 

A. Whether claims 6, 9-11, 14-15, 20, and 24-27 are properly rejected under 35 U.S.C. 
§ 103(a) as being unpatentable over U.S. Patent No. 6,721,334 
(hereinafter "Ketcham") in view of U.S. Patent Application Publication 
No. 2004/0018016 (hereinafter "O'Mahony et al."). 
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B. Whether claims 8, 13, and 23 are properly rejected under 35 U.S.C. § 103(a) as being 
unpatentable over Ketcham in view of O'Mahony et al., and further in view of 
alleged admitted prior art (hereinafter "the AAPA"). 



VII. ARGUMENT 

A. Claims 6, 9-11, 14-15, 20, and 24-27 would not have been obvious under 35 U.S.C. 
§ 103(a) from the combined disclosures of Ketcham and O'Mahony et al. 

1. Independent claims 1, 11, 20, and 26-27 

Claim 6 recites an apparatus for generating an aggregation packet in a communication 

system comprising, inter alia, " a buffer manager configured to store a plurality of data packets; 

and an aggregation module configured to receive the plurality of data packets from the buffer 

manager " (emphasis added). Claims 11, 20, and 26-27 recite similar features. Appellants 

respectfully submit that Ketcham and O'Mahony et al, even when combined, fail to teach or 

suggest at least these features. 

To the contrary, Ketcham teaches only the routers 308 and 312 which receive individual 
packets and then perform the aggregation. There is no buffer that stores a plurality packets and a 
separate aggregation module that receives the plurality of packets. In fact, Ketcham teaches 
against using the separately claimed elements, as the routers 308 and 312 include a timeout 
function such that "[i]f the timer expires before any packets with a shared LLC destination are 
received, then the packet 118 is transmitted without being aggregated." Col. 7, In. 49-52. 
Appellants note that the Final Rejection asserts that the routers 308 and 312 are each both the 
buffer and the aggregation module, but there is no feedback such that the routers receive the 
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packets from themselves. Appellants respectfully submit that Ketcham does not disclose, 
teach, or suggest at least a buffer manager that stores a plurality of data packets , and an 
aggregation module that receives the plurality of data packets from the buffer manager , as 
recited in claims 6, 11, 20, and 26-27. Nor is O'Mahony et al. cited for these features. Thus, 
O'Mahony et al. does not remedy the deficiencies of Ketcham. 

Moreover, claim 6 further recites "aggregating at least two data packets comprising a 
same destination address and identical quality of service information " (emphasis added). 
Claims 11, 20, and 26-27 recite similar features. To the contrary, O'Mahony et al., which was 
cited for teaching that the data packets comprise identical quality of service information, actually 
teaches that "the input packets are aggregated based on destination and Quality of Service (QoS) 
parameters" and "optical packets with two destinations with two QoS classes ." f [0040] 
(emphasis added). This change in terminology, from "parameters" to "classes" implies that there 
is a difference between the terms. <J[ [0038] of O'Mahony further teaches that the "LSRs 11 and 
the OPSs 10 handle the same granularity (per packet)" (emphasis added). This further bolsters 
the position that the classes of QoS may contain multiple different actual QoS values. Appellants 
respectfully submit that O'Mahony et al. does not disclose, teach, or suggest at least 
"aggregating at least two data packets comprising a same destination address and identical 
quality of service information " as recited in claims 6, 11, 20, and 26-27. The Final Rejection 
admits at page 4 that Ketcham fails to teach these features. Thus, Ketcham does not remedy the 
deficiencies of O'Mahony et al. 

Furthermore, Appellants respectfully submit that O'Mahony et al. is invalid to the extent 
that the figures, which are cited in the Final Rejection, are not fully described in or 
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understandable from the specification. For example, there is no labeling or description of the 
various shading types in FIG. 3, and there are may reference characters (e.g., S1-S5, opl-op3, 
and OTN1-OTN2) which are not described in the specification in violation of 37 CFR 1.84(p)(5). 
"Reference characters not mentioned in the description shall not appear in the drawings." Id. 

Appellants further submit that the OTN of O'Mahony et al. only supports continuous data 
streams, and offers granularity only at the wavelength level, f [0002]. Ketcham teaches against 
continuous data streams, for example, "packet 118 ... is being held for possible aggregation. . . . 
Until the timer expires or the payload of the aggregate packet is full, additional packets can be 
put into the aggregate packet." Col. 7, In. 45-49. In other words, Ketcham teaches holding 
packets for a predetermined period of time, which directly contradicts the continuous data 
streams taught by O'Mahony et al. 

In the "Response to Arguments" section, the Final Rejection alleges that "the packets are 
aggregated based on destination and QoS parameters" of O'Mahony et al., which means that they 
have to be the "same destination and same QoS." However, Appellants respectfully submit that 
this allegation has no foundation. Specifically, the phrase "based on destination and QoS 
parameters" may have various meanings, such as that the corresponded parameters are same with 
a threshold value, that the corresponded parameters are within the determined scope, and that the 
corresponded parameters coincide with the previously determined standard. Accordingly, 
Appellants do not believe that the meaning of "same" is necessarily inferred by the phrase, 
"based on." In order to show inherency, the Final Rejection must show "that the missing 
descriptive matter is necessarily present in the thing described in the reference, and that it would 
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be so recognized by persons of ordinary skill. . . . The mere fact that a certain thing may result 
from a given set of circumstances is not sufficient." See M.P.E.P. § 2112(IV) (emphasis added). 

Appellants' independent claim 6 recites, and independent claims 11 and 20 similarly 
recite, inter alia, " aggregating at least two data packets having a same destination address and 
identical quality of service information among the plurality of received data packets to form a 
single aggregated packet" (emphasis added). Similarly, claims 26 and 27 recite, "aggregating at 
least two data packets having a same destination address and identical quality of service (QoS) 
parameters among the plurality of received data packets" (emphasis added). 

Ketcham describes a system and method for a packet-based network using aggregate 
packets. Ketcham describes determining which network devices support aggregate packets. If a 
first packet is received on a route that supports aggregate packets, it is then held for a short 
period. During this short period, if an additional packet is received that shares at least one 
common route element that also supports aggregate packets with the first packet, the first packet 
and the additional packet are combined into a single larger aggregate packet. 

However, Ketcham does not describe aggregating at least two data packets having a same 
destination address and identical quality of service information from among the plurality of 
received data packets to form a single aggregated packet. The Office appears to agree that 
Ketcham is silent with regard to quality of service being used during aggregation. 

Accordingly, the Final Rejection asserts newly cited O'Mahony et al. as allegedly 
providing this feature. Appellants respectfully disagree as outlined below. 
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O'Mahony et al. describes an optical packet switch that facilitates efficient provisioning 
of packet services through a predominantly circuit- switched optical transport network 
infrastructure. In particular, the optical packet switch fits within a network where circuit and 
packet-switched traffic are transported together through the optical transport network. Fast 
switching is provided for packet traffic where granularity below the wavelength level is required, 
while slow wavelength switching and routing is facilitated at the same time. Packet traffic is 
aggregated where the optical transport network interfaces with the IP domain, which requires 
dynamic and fast wavelength allocation for packet traffic. 

In particular, the Final Rejection states that, O'Mahony et al. describes a packet system 
where packets are combined based on destination address and QOS parameters, citing 
O'Mahony et al. f [0040]. The Action goes on to assert it would have been obvious to combined 
packets based on destination and QoS parameters, as taught by O'Mahony et al., for the purpose 
of maintaining quality of service and using channels capacity wisely. 

Rather, it appears the section of O'Mahony et al. in question does not in fact disclose or 
suggest " aggregating at least two data packets having a same destination address and identical 
quality of service information among the plurality of received data packets to form a single 
aggregated packet." Instead, f [0040] of O'Mahony et al. merely discloses as follows: 

A schematic representation of the various stages in the operation of an OPS as an 
edge aggregator/router is shown in FIG. 3. In a first step 100 the OPS accepts 
packet type traffic from the service layer, i.e. IP and ATM traffic, from a number 
of sources. These packets are associated with the MPLS control plane. The 
multiple sources are signified by different header shadings in FIG. 3. In the next 
step 110 the input packets are aggregated based on destination and Quality of 
Service (QoS) parameters, and are formed into optical packets with OMPLS 
labels that signify destination and QoS class. These OMPLS labels are generated 
locally by an OMPLS control plane that functions as an intermediate control plane 
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between the MPLS control plane associated with the IP domain and the MpXS 
control plane associated with the OTN. FIG. 3 shows optical packets with two 
destinations with two QoS classes, giving three different label values. The optical 
packets are of variable length but all are an integer multiple of a chosen time unit. 
In a final step 120, the optical packets are switched to an appropriate wavelength 
channel and a new label is written into the optical packet so that it is compatible 
with the MpXS control plane of the OTN. The optical packets are then routed 
over the OTN on particular wavelengths to deaggregating nodes that are egress 
points from the OTN or to intermediary nodes that further map the optical packets 
onto new wavelength paths. Contention resolution is based on QoS class implied 
from the label on the optical packets. During the whole process the OPS runs a 
protocol capable of discovering the OXC network topology, and thus is able to 
combine aggregation with QoS provisioning within the OTN. 



In particular, Appellants point out that O'Mahony et al. describes with regard to FIG. 3 
that optical packets with two destinations with two QoS classes, give three different label values. 
The packets are formed into optical packets with OMPLS labels that signify destination and QoS 
class. Appellants note that O'Mahony et al. aggregates packets based on a QoS class, but does 
not does not disclose or suggest, the packets are aggregated to have identical quality of service 
information or parameters. It is noted that even in the Final Rejection does not assert this of 
O'Mahony et al. O'Mahony et al. only describes the generation of labels based on a QoS class . 
Therefore, even if it is assumed that it is proper to combine O'Mahony et al. with Ketcham, the 
combination does not describe all of Appellants' claimed elements. 

In addition, although the Final Rejection alleges that O'Mahony et al. is in the same field 
of endeavor, O'Mahony et al. is directed to Optical networks. In particular, O'Mahony et al. 
describes that current OXCs support continuous data streams and are not fast enough to support 
packet-by-packet switching. Therefore, the entire traffic on any OCH at an input port in an OXC 
is switched to one output port. O'Mahony et al. notes that this is an undesirable as IP traffic, for 
example, cannot be constructed as a continuous data stream. Since the OTN only supports 
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continuous data streams, it offers granularity only at the wavelength level. Thus if the channel 
traffic is bursty the channel capacity may be underused, which has an impact on the 
dimensioning of the network and the size of the OXCs required. In hybrid communications 
networks including an electronic network and an optical network, a uniform control strategy is 
needed. 

As a result, O'Mahony et al. points out one of the main disadvantages of an OTN is that 
there is currently no mechanism to provide direct access to the OTN with bandwidth granularity 
that is finer than a whole wavelength, and that "Providing this finer granularity is central to 
creating a network that is efficient, from the perspective of the operator, and cost effective, for 
the operators customer." (See O'Mahony et al. f [0035]). O'Mahony et al. solves this by using 
external electronic routers and OPSs that handle the same granularity (per packet), which will 
lead to an integrated control plane between the IP and the OTN domains. At the same time, each 
OPS maintains information on the configuration, the physical infrastructure, the topology and 
scale of the OXC transport. Therefore, the OPS of O'Mahony et al. is able to isolate the OTN 
from the service layer while interfacing fully with both layers, i.e., with the data/IP domain 
through integrated management control, and with the OTN by maintaining information on the 
configuration, the physical infrastructure, the topology and scale of the OXC transport (See, e.g., 
f [0034]). The edge aggregator router of FIG. 3 performs this function. As such, O'Mahony 
et al. teaches an aggregation technique to provide direct access to the OTN with bandwidth 
granularity that is finer than a whole wavelength. 

In contrast, at col. In. 15-29, Ketcham notes that if the actual size of most packets is 
significantly less than the maximum size, the network is not operating at maximum efficiency. 
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This is because Ethernet is a carrier sense multiple access (CSMA) protocol with collision 
detection (CD). The transmission times are setup based on the maximum packet size and a 
maximum cable length. Contention periods for access to the common transmission medium are 
placed in between the packet transmission slots. This means that the packet sizes for higher 
speed Ethernet protocols are larger, or the maximum cable length must be shortened. 
Additionally, the contention period between transmission of successive packets adds another 
delay to the transmission of data. On an IEEE 802.3, standard 10 Mbps Ethernet, the per packet 
overhead is 20.8 jasec and there is a minimum 9.6 jasec gap between packets. Therefore, 
Ketcham describe an aggregation technique that allows the bandwidth of a common medium to 
be more fully used because more of the packets will be closer to the maximum size allowed. 

Furthermore, O'Mahony et al. describes that various types of packets outputted from an 
upper layer in an optical network(i.e., the service layer) are aggregated in a multiprotocol label 
switching (MPLS) control plane. (See, e.g., O'Mahony et al. f [0040]: in a first step 100 the 
OPS accepts packet type traffic from the service layer, i.e., IP and ATM traffic, from a number of 
sources. These packets are associated with the MPLS control plane.). In contrast, Ketcham 
describes aggregation on an Ethernet layer and only aggregates the packets with in a same layer. 
Therefore, the multilayer system of O'Mahony et al. may not readily be combined Ketcham. 

It is respectfully submitted that Ketcham is not directed to Optical Networks and that that 
one of ordinary skill in the art would not have looked to O'Mahony et al. for an optical network 
technique. Moreover, the technique of O'Mahony et al. would thwart the intended purpose of 
Ketcham to provide optimum use of packets by size which is important in contention resolution 
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for the network described. Therefore, Appellants assert that it would not have been obvious to 
render Ketcham unfit for its intended purpose. 

Moreover, in The Court in KSR v. Teleflex held that a prima facie case of obviousness 
requires an apparent reason why a person of ordinary skill in the art would combine the 
references, and that the analysis must be made explicit. KSR v. Teleflex, 550 U.S. 398 (2007). In 
addition, a rational must be provided for any modifications of the prior art. "[Rejections on 
obviousness cannot be sustained by mere conclusory statements; instead, there must be some 
articulated reasoning with some rational underpinning to support the legal conclusion of 
obviousness." KSR, 550 U.S. at 399, 82 USPQ2d at 1396 (quoting In re Kahn, 441 F.3d 977, 
988, 78 USPQ2d 1329, 1336 (Fed. Cir. 2006)). In this case, the reason provided by in the Final 
Rejection (i.e., "for the purpose of maintaining quality of service and using channels capacity 
wisely") is not apparent since the system of Ketcham already maintains quality of service by and 
using channels capacity wisely by aggregating and does not appear to be concerned with Quality 
of Service. In addition, Ketcham already discloses a technique for using channel capacity 
wisely. Therefore, it is not apparent why one of ordinary skill in the art would have modified 
Ketcham for a reason for something that Ketcham already does. In addition, no analysis, 
"explicit" or otherwise, is provided on how the proposed combination of references would 
provide the alleged "or the purpose of maintaining quality of service and using channels capacity 
wisely." Therefore, the Final Rejection has not met its burden to establish a prima facie case of 
obviousness. 

Since Ketcham and O'Mahony et al. are not properly combinable and do not teach or 
suggest all of the features of claims 6, 11, 20, and 26-27, claims 6, 11, 20, and 26-27 are not 
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obvious over the cited combination. Appellants respectfully request that the 35 U.S.C. § 103(a) 
rejection of claims 6, 11, 20, and 26-27 be reversed and the claims allowed. 



2. Dependent claims 9-10, 14-15, and 24-25 
Claims 9-10, 14-15, and 24-25 depend, respectively, from independent claims 6, 11, 
and 20, and are patentable at least for the reasons mentioned above, and on their own merits. 

For example, claims 9, 14, and 24 each further recite that "the header of the aggregation 
packet further comprises the length information of each of the at least two data packets." 
[Specification, FIG. 9, 920; page 5, In. 8-9], Appellants note that the Final Rejection only cites a 
col. 3, In. 1-5, but does not specify whether this refers to Ketcham or O'Mahony et al. 
O'Mahony et al., being a publication, has only paragraph numbers, not column and line numbers. 
Ketcham's col. 3, In. 1-5 teaches that "each aggregate packet includes a fixed sized table that 
describes the locations and size of the embedded packets." In fact, Ketcham teaches that the 
"payload flag 702 is followed by a fixed size table with entries for i embedded packets." FIG. 7 
of Ketcham (reproduced below on the next page) shows that the payload 700, which contains the 
payload flag 702, follows the headers 210, 212. Thus, Appellants respectfully submit that 
Ketcham in view of O'Mahony et al. does not disclose, teach, or suggest that "the header of the 
aggregation packet further comprises the length information of each of the at least two data 
packets," as recited in claims 9, 14, and 24. 
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Ketcham FIG 7 




HDLC LLC FIG - 7 

Furthermore, claims 10, 15, and 25 each further recite that "the length information 
comprises information about a data length of each of the at least two data packets." 
[Specification, FIG. 9, 920; page 5, In. 8-9]. This feature is not even mentioned in the Final 
Rejection. Accordingly, the Final Rejection fails to establish a prima facie case of obviousness 
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for at least claims 10, 15, and 25. Appellants further incorporate the above arguments with 
respect to claims 9, 14, and 24, on which claims 10, 15, and 25 respectively depend. 

Appellants respectfully request that the 35 U.S.C. § 103(a) rejection of claims 9-10, 
14-15, and 24-25 be reversed and the claims allowed. 



B. Claims 8, 13, and 23 would not have been obvious under 35 U.S.C. § 103(a) from the 
combined disclosures of Ketcham, O'Mahony et al„ and the AAPA 

Claims 8, 13, and 23 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over 
Ketcham in view of O'Mahony et al, and further in view of alleged admitted prior art (AAPA). 
This rejection is respectfully traversed. Claims 8, 13, and 23 depend, respectively, from 
independent claims 6, 11, and 20, and are patentable at least for the reasons mentioned above, 
and on their own merits. 

For example, claims 8, 13, and 23 each further recite that "the aggregated packet 
comprises a data section corresponding to each of the at least two data packets, the data 
section preceding the corresponding data packet " (emphasis added). [FIG. 5, 342, Length 1, 
Packet 1 344, Length n, Packet n 344]. This feature is not even mentioned in the Final Rejection. 
Accordingly, the Final Rejection fails to establish a prima facie case of obviousness for at least 
claims 8, 13, and 23. In addition, the AAPA, which consists of FIG. 2 of the present specification 
(reproduced below on the next page), shows that the aggregated packets 24, in order to reduce 
resources, use only one overhead 26, which precedes the entire set of data 18, 20. FIG. 5, which 
shows the claimed corresponding data sections and packets, is also reproduced for comparison. 
Accordingly, the AAPA does not disclose, teach, or suggest "a data section corresponding to each 
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of the at least two data packets, the data section preceding the corresponding data packet ," as 
recited in claims 8, 13, and 23. 
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Appellants respectfully request that the 35 U.S.C. § 103(a) rejection of claims 8, 13, 
and 23 be reversed and the claims allowed. 
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VIII. CONCLUSION 

For each of the foregoing reasons, Appellants respectfully submit that the claimed 
invention is non-obvious over the cited prior art. Reversal of each of the final grounds of 
rejection is respectfully solicited. If the Examiner believes, for any reason, that personal 
communication will expedite prosecution of this application, the Examiner is invited to 
telephone the undersigned at the number provided below. 



Respectfully submitted, 



Dated: October 6, 2010 



By: /Rachael Lea Leventhal/ 
Rachael Lea Leventhal 



Reg. No. 54,266 
NSIP Law 

1156 15th Street NW, Suite 603 
Washington, DC 20005 
Tel: (202)429-0020 



RLL/ 
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APPENDIX A - CLAIMS APPENDIX 

1-5. (Canceled) 

6. (Previously Presented) An apparatus for generating an aggregation packet in a 
communication system, the apparatus comprising: 

a buffer manager configured to store a plurality of data packets; and 
an aggregation module configured to receive the plurality of data packets from the buffer 
manager and aggregating at least two data packets comprising a same destination address and 
identical quality of service information among the plurality of received data packets to form a 
single aggregated packet, a header of each of the at least two data packets comprising length 
information and a destination address, a header of the aggregated packet comprising a destination 
address which is identical to the destination address included in the header of the at least two 
data packets. 

7. (Canceled) 

8. (Previously Presented) The apparatus of claim 6, wherein the aggregated packet 
comprises a data section corresponding to each of the at least two data packets, the data section 
preceding the corresponding data packet. 

9. (Previously Presented) The apparatus of claim 6, wherein the header of the aggregated 
packet further comprises the length information of each of the at least two data packets. 

10. (Previously Presented) The apparatus of claim 9, wherein the length information 
comprises information about a data length of each of the at least two data packets. 

11. (Previously Presented) A method for generating an aggregation packet in a 
communication apparatus of a wireless communication system, the method comprising: 

receiving a plurality of data packets in a buffer manager of the communications 
apparatus; 
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aggregating, by an aggregation module of the communications apparatus, at least two 
data packets comprising a same destination address and identical quality of service information 
among the plurality of received data packets; and 

generating, by the communications apparatus, a single aggregation packet from the 
aggregated packets by adding a header to the aggregated packets, a header of each of the at least 
two data packets comprising length information and a destination address, the header of the 
aggregation packet comprising a destination address which is identical to the destination address 
included in the header of the at least two data packets. 

12. (Canceled) 

13. (Previously Presented) The method of claim 11, wherein the aggregation packet 
comprises a data section corresponding to each of the at least two data packets, the data section 
preceding the corresponding data packet. 

14. (Previously Presented) The method of claim 11, wherein the header of the 
aggregation packet further comprises the length information of each of the at least two data 
packets. 

15. (Previously Presented) The method of claim 14, wherein the length information 
comprises information about a data length of each of the at least two data packets. 

16-19. (Canceled) 

20. (Previously Presented) A method of generating an aggregation packet in 
communication apparatus of a wireless communication system, the method comprising: 

receiving, by a buffer manager of the communications apparatus, a plurality of data 
packets and quality of service information associated with the packets, each of the data packets 
comprising a destination address and length information; 
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aggregating, by an aggregation module of the communications apparatus, at least two 
data packets comprising the same destination address and identical quality of service information 
among the plurality of received data packets; and 

generating a single aggregation packet from the aggregated packets by adding a header to 
the aggregated data packets, the header comprising the destination address of the aggregated data 
packets. 

21-22. (Canceled) 

23. (Previously Presented) The method of claim 20, wherein the aggregation packet 
comprises a data section corresponding to each of the at least two data packets, the data section 
preceding the corresponding data packet. 

24. (Previously Presented) The method of claim 20, wherein the header of the 
aggregation packet further comprises the length information of each of the at least two data 
packets. 

25. (Previously Presented) The method of claim 20, wherein the length information 
comprises information about a data length of each of the at least two data packets. 

26. (Previously Presented) An apparatus for generating an aggregation packet in a 
communication system, the apparatus comprising: 

a buffer manager for storing a plurality of data packets; and 

an aggregation module for receiving the plurality of data packets from the buffer manager 
and aggregating at least two data packets comprising a same destination address and identical 
quality of service (QoS) parameters among the plurality of received data packets to form a single 
aggregated packet, a header of each of the at least two data packets comprising length 
information and a destination address, a header of the aggregated packet comprising a destination 
address which is identical to the destination address included in the header of the at least two 
data packets. 
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27. (Previously Presented) A method for generating an aggregation packet in a 
communication apparatus of a wireless communication system, the method comprising the steps 
of: 

receiving a plurality of data packets in a buffer manager of the communications 
apparatus; 

aggregating, by an aggregation module of the communications apparatus, at least two 
data packets comprising a same destination address and identical quality of service (QoS) 
parameters among the plurality of received data packets; and 

generating, by the communications apparatus, a single aggregation packet from the 
aggregated packets by adding a header to the aggregated packets, a header of each of the at least 
two data packets comprising length information and a destination address, the header of the 
aggregation packet comprising a destination address which is identical to the destination address 
included in the header of the at least two data packets. 



25 



Application No. 10/782,193 
Appeal Brief 



Attorney Docket No. 12000.SMG.0008 



APPENDIX A - EVIDENCE APPENDIX 



None. 
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APPENDIX C - RELATED PROCEEDINGS APPENDIX 



None. 
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